home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19980901-19981211 / 000221_news@newsmaster….columbia.edu _Tue Oct 27 11:08:04 1998.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id LAA18683
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Tue, 27 Oct 1998 11:08:04 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id LAA11257
  7.     for kermit.misc@watsun; Tue, 27 Oct 1998 11:08:03 -0500 (EST)
  8. Path: news.columbia.edu!panix!logbridge.uoregon.edu!xmission!news.cc.utah.edu!cc.usu.edu!jrd
  9. From: jrd@cc.usu.edu (Joe Doupnik)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Q. about running kermit over a proprietary transmission network
  12. Message-ID: <NnDzx8U6YImc@cc.usu.edu>
  13. Date: 27 Oct 98 08:13:02 MDT
  14. References: <713hfu$3na$1@nnrp1.dejanews.com>
  15. Organization: Utah State University
  16. Lines: 75
  17. Xref: news.columbia.edu comp.protocols.kermit.misc:9421
  18.  
  19. In article <713hfu$3na$1@nnrp1.dejanews.com>, tony_w_k_wu@my-dejanews.com writes:
  20. > Hi
  21. > 
  22. > I want to run kermit over 57600 baud async. serial through a
  23. > proprietary transmission system/network and comes out serially
  24. > into another device. The typical transfer file size are
  25. > about 300Kbyte. (up to 1 -2 Mbyte max)
  26. > 
  27. > The proprietary transmission system is a CSMA/CD kind of LAN.
  28. > Its speed is around 44Kbaud and it is NOT noisy.
  29. > Note: the proprietary transmission system is about 10-20%
  30. > slower than the serial link.
  31. > It support :
  32. > a) UNACK type of transmission of data packet with 88bytes data
  33. >    payload. (quick and no guarantee of delivery)
  34. >    latency is about 40 ms per 88bytes data packet.
  35. > 
  36. > b) ACK type of transmission with segmentation/reassembly capability
  37. >    and arbitrary data length. (guarantee delivery)
  38. > 
  39. > I need to build some software in the proprietary transmission system
  40. > to convert the kermit over serial into
  41. > either a) or b) type of transmission format. (or even combination of
  42. > both)
  43. > 
  44. > Note: there is no HW flow control ie RTS/CTS between the serial
  45. >       link
  46. > Note: XON and XOFF is delivered transparently to the target device.
  47. > 
  48. > Original thought is to build something extremely simple base on
  49. > a) type of transmission.
  50. > With a scheme like the follow:
  51. >    send a packet if I receive 88bytes serially or I have not
  52. >    send a packet in last 20ms and send whatever number of bytes
  53. >    I have received.
  54. > 
  55. > Alternatively,
  56. >    I can look at the kermit initialization and negotiation sequence
  57. >    to figure out the packet length, window size. Look for the ^A and
  58. >    EOL to delimit each packet. And pack each kermit packet into
  59. >    type a) or type b) transmission adaptively. e.g. ACK/NAK kermit packet
  60. >    on type a) and data packet on type b).
  61. > 
  62. > 
  63. > What do you think about the 2 schemes? Would I be able to gain any throughput
  64. > improvement with the alternative scheme? How would you configure the window
  65. > size and packet size in kermit to maximize throughput? Any thing I should
  66. > take special care of when I am building something described above? Any other
  67. > ideas to get the max througput?
  68. -------
  69.     The Kermit protocol presumes "the wire" is noisy, lossy, and generally
  70. anxious to destroy data. Thus Kermits provide error checking, retries,
  71. timeouts, sequence numbers, and selective repeat sliding windows. All but
  72. the last are requirements for a robust protocol independent of the quality
  73. and delay of "the wire."
  74.     If you add reliability (point to point low level ACKs and retries)
  75. to your wire (speaking algorithmically) then that reliability introduces
  76. time delays. Those delays can compete with what Kermit does, and it is
  77. not simple to predict the maximum throughput combination.
  78.     What your wire lacks is flow control, the killer of many comms links.
  79. Fix that and let the high level protocols, such as Kermit, take care of
  80. recovering from missing data.
  81.     It is a very un-good idea to try spoofing protocols by providing
  82. synthetic ACKs and so on. The wire lies like a bandit because while ACKing
  83. to the Kermit sender it has in fact not delivered the data to the far
  84. end. And your scheme will be out of date as the protocol details evolve.
  85. Telebit tried this with their modems and the results were not worth the
  86. effort. I shudder each time I see an outfit try faking things this way.
  87.     One guesses you are playing with a radio link, a cell phone or
  88. similar spread spectrum arrangement. Just get flow control implemented
  89. so that overrun data loss is miminised at the interfaces to the high level
  90. protocols. The protocols will take care of the rest, and one then tunes
  91. them based on particular link characteristics.
  92.     Joe D.
  93.     Joe D.